that’s basic coding 101 folks, scary isn’t it?

first, maven 3 doesn’t support scp/ssh out of the box. why, i don’t know and i find it amusing that maven 2 is the one providing scp support but ok, that’s not the worst thing in the world, right?

wrong…

once again, i have to add another chunk of xml

<plugin>
...
  <dependencies>
    <dependency>
      <groupId>org.apache.maven.wagon</groupId>
      <artifactId>wagon-ssh</artifactId>
      <version>1.0</version>
    </dependency>
  </dependencies> 
</plugin>

to the pom.

maven has the ability to auto-load extensions for you using the <extensions> tag, but alas, the site plugin doesn’t expose it. doing so would make it easier on end users and those that really care about unnecessary dependencies being downloaded (how can they tell anyway, it seems every time i tweak my poms maven’s downloading something else) can control specify the specific wagon(s) they want.

but ok, having to edit the pom isn’t that bad. i have to do it for everything else, so why should this be any different?

what i find to be truly annoying in this case is the scp url doesn’t support tildes (~), which means i have to hard code the full path to my hosted home directory – which has the potential to change if they migrate my account to another machine – otherwise it tries to create the destination directory under / on the hosting server. it seems like there should be some kind of allotment for this, but there is not.

i filed an enhancement, we’ll see what happens.

p.s. i tried every a few variations of the tilde in the url and none worked – if there’s a way this can be done, i will happily admit i was wrong and withdraw this portion of my hate.

p.p.s just so there’s a little love, the site plugin is one of the reasons i decided to stick with maven instead of creating build scripts with ant.

fast forward to today and i find myself spending some significant time with maven again (specifically version 3.0) and while some things have improved greatly, others have not.

for instance, this documentation states that the user.name property is used to populate the Built-By attribute of a manifest file. well, that’s all fine and good if i want to use that value, but what happens if i want to change it?

you can’t add this to your pom:

 <properties>
    <user.name>foo</user.name>
 </properties>

instead you have to do define a configuration for the plugin, like so:

<plugin>
  ...
  <configuration>
    <archive>
      <manifestEntries>
        <Built-By>foo</Built-By>
      </manifestEntries>
    </archive>
  </configuration>
</plugin>

that might not be so bad if there was a way to define that configuration as a reusable block, but you can’t! you have to define that same configuration for every plugin that can produce an archive package, ie: maven-javadoc-plugin, maven-source-plugin, etc.

why is there no property exposed that allows you to override this value, falling back to user.name as a default!?!?!

i filed bug MJAR-155 to try and get a property exposed, but there’s been no movement on the bug, so i’m not entirely hopeful. i guess i could submit a patch, but there aren’t enough hours in my day to work on my own projects, let alone someone else’s.

annoying to say the least and compounded further when you are working on multiple projects that all share the same general configuration. yes, you can create a parent pom, which i have decided to do just to make my life easier, but i shouldn’t have to.

enough of that for now…stay tuned for what is sure to become an ongoing series on the topic.

p.s. i also realize i could go back to using ant instead, but there are some things about maven i like and given it’s a requirement to use tycho, i would prefer to use a consistent build tool for all my projects.

project hosting has moved away from google code and over to github – i really like that github offers the ability to create an ‘organization‘ to house projects under instead of just a personal account.

as for perlipse, which is the real reason you’re here…stay tuned for the up and coming 2.0 (that’s right, 2.0) release!

after two weeks of on and off trial and error, mostly error, i finally have a working implementation that creates heredoc document partitions, which allows for fun things like syntax highlighting.

i spent way too much time trying to figure out how to reposition the character scanner within the partition when the simple solution was just to reparse starting at the first identifier.

this will be included in the dltk 4.0 release scheduled for sometime next week, which means it will make its way to you shortly there after.

here’s what’s new and noteworthy:

• java 1.6 is now required
• updated plugin versions to use a ‘qualifier’
• added ‘branding’ plugin
• no longer uses deprecated dltk methods*
• parser bug fixes and AST work
• ppi4j parser is now the default parser on new installations
• issue 26 has been fixed and a new preference introduced to set the color of back tick strings

the thing i am most excited about in this release though are the new icons provided by new project contributor, james lauer!

head on over to the project page for more details.

* the one exception to this is code folding which is going to require an entire re-write.

at the moment, only ‘use’ statements are included in the view as i haven’t quite figured out how best to distinguish the remaining types (‘no’ and ‘require’) in the tree.

i was thinking about either a text representation where ‘u’ is for ‘use’, ‘n’ is for ‘no’ and ‘r’ is for require, i.e. (yes, this is contrived):

  [u] strict

  [n] warnings

  [r] Data::Dumper

or a different image/icon, which of course, i would have to create and my image skills suck.

looking forward, my plan is to continue enhancing the AST while introducing new functionality that depends on it. currently i have my sites focus on some basic hyperlink support.

head on over to the project page for more details.

oh, one more thing, if you installed using the update-site, just tell eclipse to check for new updates and it should find the latest release.

i’ve reached out to the active state folks but until i get a response from them, there isn’t much i can do.

however, there is a work around! i have made an older copy of the dbgp implemenation here, so if you install that, you should be good to go.

the 1.0.0 release brings perlipse in line with the 3.0 release of the dltk and also introduces initial support for a source parser based on ppi4j.

head on over to the project page for more details.

note: i just realized that i should probably include the caveat that there is not a lot of polish behind the source parser right now and it is possible that runtime exceptions could be thrown when parsing code. if you encounter this, please file a bug report and include a snippet of code that demonstrates the issue.

i am happy to report that after some head banging, i have fully ported PPI’s tokenizing logic and am well on my way with the parser, having finally figured out how to deal with this:

  if ( ref $Parent eq 'PPI::Statement' )
  {
      bless $Parent, 'PPI::Statement::Compound';
  }

in java.

the trick was to use a temporary object that i could store the class type on and then convert to that object before adding it to the overall document. with that hurdle out of the way, all that is left (i hope) is some straight forward logic porting.

it’s still too soon to say when this will be ready, especially with an upcoming trip to amsterdam, but i’m really hoping for the end of march.